EnigmA Amiga Run 1996 February/EnigmA AMIGA RUN 04 (1996)(G.R. Edizioni)(IT)[!][issue 1996-02][Skylink CD III].iso/earcd/faq/q_log.lha/q.log

Text File | 1995-11-22 | 42KB | 779 lines

       Sch > I'd liek to introduce JeremyG to you all
       Sch > JeremyG say hi :)

   JeremyG > Hey all...

       Sch > Jeremy has been developing an OS for about 5 years now
       Sch > It was developed on the Amiga and is actually portable to other platforms
       Sch > It's hardware independent.  Some of the features it has are Memory
             Protection, Retargetable graphics, AutoConfig Networking and much more
       Sch > Jeremy: Is there anything you want to say about the OS before we start?

   JeremyG > I've got a few paragraphs I can send if you want...

       Sch > Please do

   JeremyG > Q Operating System is the first fully hardware and interface
             independant operating system. This allows it to do some interesting
             things, such as DOOM on an Amiga, or an Amiga paint program on a 16
             processor Cray YMP-C90. It is fully capable of "forcing" the issue,
             if the program
   JeremyG > doesn't want to cooperate. Impossible? It is, with current OS
             technology. That is why we've had to start from scratch, completely
             rebuilding the philosophy of OS design. No longer is the end user at
             the
   JeremyG > mercy of the applications programmers. Instead of lowering the system
             to match as many applications as possible, Q raises those
             applications to meet the system. This is retargetability at its
             ideal.
   JeremyG > At long last hardware designers will be free from compatibility
             worries, and applications programmers don't have to support all of
             the "standards" out there. In fact, they don't have to support any!
   JeremyG > The techniques we use to do what we do also offer many other
             advantages, such as some of those previously discussed.
   JeremyG > Because of the way it handles the applications, things such as crash
             proofing, resource management, auto-caching, virus resistance,
   JeremyG > full retargetability, and many other features become possible.

       Sch > Jeremy: When you're done, just let me know so I can give out the
             rules for the conference and people can have a little while to think
             of their questions :)
       Sch > Ok
       Sch > Ok folks: You will be /msging me with your questions
       Sch > I will be on as Schrade.  Please send msgs to him and him ONLY
       Sch > Question asking is ONLY for the undernet side of the net due to the
             instability of EFFNet
       Sch > Ok..here we go
       Sch > First question from Dagorgil
       Sch > "How does this promotion of applications happen?"
       Sch > DO NOT MSG me as Sch.  Send MSGS to Schrade ONLY

   JeremyG > The basic idea is that it reads the program, converts it to it's own
             language (called UML) and the converts that language back to the
             machine code needed to run
   JeremyG > on your machine. Obviously its much more complex than this, but
             basically that's how it works. It is a recompilation type metho
   JeremyG > GA

   Howard > Wont memory protect and crash-proofing cause the OS to slow dow
             drastically compared to the kickstart in use today?

   JeremyG > Nope, in fact it will operate considerably faster. Let me explain
             something that will give you a better idea
   JeremyG > of what kind of techniques are used. For starters an MMU is not used
             AT ALL. It is not needed. Virtual memory is a thing of the
   JeremyG > past. Memory protection has moved to higher planes.
   JeremyG > You have to pay for it of course. And it is done when you "prep" a
             program when it is first installed on your system.
   JeremyG > It could take several hours before that program is available to you,
             but once it's prepped, it will operate as fast or faster
   JeremyG > than under more primitive systems. In addition, each time you run a
             program it gets a little bit faster, optimizing itself to
   JeremyG > the peculiar ways that you use it. In fact, an assembly language
             programmer would have a difficult time coding tighter and more
   JeremyG > precisely than Q can. Later on as Q becomes more developed, we will
             actually hold contests, to see if assembly programmers can
   JeremyG > program more efficient code than Q can... I know this sounds like a
             tall order, but it's no longer just an idea on paper,
   JeremyG > it is a working product being put through the final stages of
             testing.
   JeremyG > GA

     Vicce > "I would like to know how he would market the OS."

   JeremyG > There are several different techniques being thrown around, and many
             of them will be employed. Make no mistake, Q
   JeremyG > will run on anything powered with a processor with 256k of RAM or
             more... That means that pretty much the entire computer
   JeremyG > industry is our market. As far as personal computers are concerned,
             the Amiga in particular, we have spoken with
   JeremyG > Amiga Technologies, and if they can get over their doubt and
             unbelief, we will demonstrate it to them as soon as they
   JeremyG > are willing. We would prefer to sell our product packaged with
             computers, and not to sell it on the open market directly.
   JeremyG > GA

      Zool > No offense, but is this real?  I mean, it seems impossible: A
             programmer announces a new OS which he's been working on alone for 5
             years, no one has ever heard of it, and it has features that make
             all other OS look hideous?  Sounds too good to be true.

   JeremyG > Good question and completely understandable.
   JeremyG > If you think about it for a while, you might figure out why we keep
             it low-profile, at least up until now.
   JeremyG > Sorry for the vagaries, its a good question, I just can't answer
             without making a lot of people angry...
   JeremyG > GA

      oleg > "What language is the OS written in?"

   JeremyG > Q is written in Q... :) yes, Q is a programming language, and the
             only one powerful enough to pull off something like itself.
   JeremyG > Bootstrapping was the only way to get it to the public in less than a
             century. C++ programming is a ridiculously slow
   JeremyG > development process comparatively. The original "contrictor" is
             written in 68040 assembly language, and is the
   JeremyG > seed bootstrapping code for Q itself. But the vast bulk of Q is
             written in Q.
   JeremyG > Oh, by the way, I am not by any means the only one developing this, I
             am just the one who designed the core of Q. GA

  Frac_unet > "How did Q come about?  Just a personal project?  University or
             industry linked research?"

   JeremyG > It came about as a desparate programmers attempt to make programming
             an easier process.
   JeremyG > It started as small alterations of C++, and expanded to what we call
             a SuperCompiler.
   JeremyG > Then we realized that by running this supercompiler under most
             operating systems, it would be seriously inhibited.
   JeremyG > So we designed it AS an operating system. Because of its nature, it
             made a REAL NICE operating system, even though that
   JeremyG > wasn't the intention. It became an ideal development utility for us
             as we could code for several different platforms AT tHE
   JeremyG > SAME TIME. In other words, we could write a word processor in Q, and
             have it spit out executables for Amigas, Windows,
   JeremyG > Macs, etc. with almost no extra effort. GA

     gregh > "Availability?  How much?"

   JeremyG > We are actually going to release an early version for Amigas as
             licenseware (completely free).
   JeremyG > That of course depends on several other factors, it may not happen.
             The money comes from extras that may be attached
   JeremyG > to the operating system, such as extra interfaces, hardware
             description modules, drivers, etc. There will be a develope
   JeremyG > version, but it will cost a lot, possibly over a grand... GA

      Robr > What is your URL address, and when can we see screen shots?"

   JeremyG > I am currently working on getting a web page up. No screen shots yet,
             for legal and logical reasons.
   JeremyG > Just to add something quickly to the last question, we're looking at
             1st quarter of 96 for the free Amiga release.
   JeremyG > The logical reasons I am referring to consists of the simple fact
             that no two Q systems look alike. Being interface
   JeremyG > independant, and being more configurable than even the most flexible
             of interfacing programs, it
   JeremyG > ... ah you get the point. About the end of the year we will be
             permitted to show it off, and then I can upload some of my
   JeremyG > favorite interfaces. GA

     Cappy > "What background in programming Amiga and other platforms do you
             have?"

   JeremyG > Lets see... I have done database programming for a long distance
             company for a few years. I have a small amount of experience
   JeremyG > in the PC world, but much more in the Amiga world. Just private stuff
             though, nothing I have coded has ever been released.
   JeremyG > GA

     neyda > 1) Where does one buy this OS (answered) 2) Where does one get
             developer kits (please be specific) 3) Why haven't there been any
             demos or talk of or news about this OS?

   JeremyG > To answer question 2, you don't. Not yet. For one thing you don't
             need them, because all operating system programs will work,
   JeremyG > provided that they are properly described. There will be developer
             kits eventually, but we really don't have to
   JeremyG > go around to all the developers and beg for them to support us.
   JeremyG > To answer question 3 this is the first time that I was permitted to
             talk about it on the internet. This IS the talk
   JeremyG > and the news. Demos? Our first is in mid December and is open to
             anyone who wants to be there. In fact, I am trying to
   JeremyG > get our people to let me release betas to all of the people who come
             to the demo (after signing a form, of course).
   JeremyG > The details of the demo are being hammered out and I will post the
             results as soon as I get them. GA

     TaoTe > 1) Where does one buy this OS (answered) 2) Where does one get
             developer kits (please be specific) 3) Why haven't there been any
             demos or talk of or news about this OS?
     TaoTe > Also thrown in from TaoTe: Does Q support multithreading?  and is
             there an FAQ?
     TaoTe > How well does Q work as a server, i.e. for SQL database processing?

   JeremyG > No FAQ yet, and yes it does support multi-threading, (and even a few
             new concepts)
   JeremyG > It works as well as the descriptors written for it.
   JeremyG > As a server it is a dream, fault tolerance, high performance
             operation,
   JeremyG > extremely easy to use, full multi-user support, and many others...
   JeremyG > GA

      doZE > "Have you taken your ideas from OS9?"

   JeremyG > What is OS9? GA

       Sch > OS9 is an OS that was popular on the tandy color computer :)
       Sch > not was, IS... it still exists
       Sch > It is now being used as an OS for CDi type components and also for
             Kiosks

   JeremyG > Okay, I guess the answer is no. Some stuff I would like to add to the
             networking questions...
   JeremyG > I will now elaborate a little on the networking side of it, I think
             it would answer many questions.
   JeremyG > Let me point out some attributes of it and you figure out how it
             works... For starters it is
   JeremyG > capable and in fact does create its own protocols over any piece of
             hardware if you give it the chance.
   JeremyG > This means that if I hooked up the parallel and serial ports as well
             as an ethernet connection between two computers,
   JeremyG > Q would automatically come up with a protocol to work most
             efficiently over the configuration.
   JeremyG > ALL resources are shared between the computers (user alterable of
             course). This includes processing power and RAM, and
   JeremyG > all IO resources. I.E. If I ran lightwave on an Amiga with a Pentium
             attached (however it is attached), if the task
   JeremyG > feels like it, and if there is free processor on the Pentium, the
             task will be completed by BOTH processors. I know that
   JeremyG > this sounds crazy, but parallel processing is Q's birthright. It is
             actually quite easy with the techniques it uses. I could
   JeremyG > write a lot more about this but I will stop for now. GA

     Frotz > Why on earth did start developing a replacement for AmigaDOS 5 years
             ago, and why hasn't ANYBODY seen this thing running?  (partially
             answered)

   JeremyG > This is NOT a replacement for AmigaDOS. It is true that it does
             replace it, but that WASN'T the intention.
   JeremyG > We DIDN'T want people to know about this until we were about ready to
             release it. You see there are many companies
   JeremyG > out there would would much prefer that we never surface with a
             product. We have had to of necessity keep it quiet until we
   JeremyG > could better protect our investment. GA

  Trooper1 > Question: How can Amiga programs be memory protected, when sharing
             memory is hardly ever done explicitly on the Amiga?1

   JeremyG > Could you rephrase the question?
   JeremyG > GA

    deltax > How big is the kernel?  What kind of system resources does it need?"

   JeremyG > The kernal is relatively small, simply because most resources reside
             inside of classes and objects on the hard drive.
   JeremyG > The system resources it needs are remakably small, again because of
             the nature. It has been run under 256k of RAM.
   JeremyG > The more RAM you can give it though the faster it will go. In fact,
             running a program that normally requires 1 meg of ram
   JeremyG > (say a fractal program) in 100 megs of ram will INCREASE its speed
             considerably. Space-time conversions are part of the
   JeremyG > resource management subsystem. The actual Q on the hard drive may be
             anywhere from 10 megs to several Gigs depending on
   JeremyG > how you do it and what system it is run on, as well as which hardware
             descriptions you want, which interfaces, etc.
   JeremyG > GA

  Trooper1 > "When one allocates memeory in an Amiga program, this is almost never
             done using the MEMF_PUBLIC flag.  Still, the allocated memory is
             used by several different programs.
  Trooper1 > How do you know that his is what happens, and that the other program
             is not violating the first?"

   JeremyG > Good question, and the answer is QUITE involved. Nor would I describe
             it, because that goes deep into the core. However,

       Sch > huh

   JeremyG > I will attempt to explain breifly what goes on concerning situations
             like this so that you can know that this is real.

     Cappy > hahaha

   JeremyG > Each time Q takes apart a program and attempts to figure out what's
             going on, it must perform a complex juggling act,
   JeremyG > one that isn't always completely successful, although it almost
             always comes up with SOME solution...
   JeremyG > The basic idea is the whole art of Q and that is attempting to match
             up what a program seems to do with what the
   JeremyG > programmer actually intended to happen. Don't worry though, if it
             works under the Amiga's OS it will work under Q.
   JeremyG > even if some settings need to be changed... Sorry, kinda vague, but
             that's the best I can do right now... GA

       Sch > Jeremy: Just a little note. We have seen wonderful promises from a
             gentleman named Jim Drew before.  He promised lots but never
             delivered.
       Sch > When are you going to show some proof?
       Sch > (This is from me)

   JeremyG > I have already explained that there is a demonstration in mid
             December... It will be held in Mesa, Arizona, USA.

       Sch > OK.

   JeremyG > GA

 BloodHawk > "Will I be able to get 040 performance out of my 000 machine with
             Q-OS?" (uh.......huh huhh huhh)

       Sch > I think not.
       Sch > :)

   JeremyG > Nah. But on average things should move 20-50% faster. Even more so if
             you know what you're doing. GA

  Fastlane > Why do we all get the feeling that this is a total load of bullshit
             that you are spouting, and why are you obviously dodging questions?

   JeremyG > The difference is that Jim Drew wanted something from people... I am
             simply telling people that when this is available on the
   JeremyG > internet, give it a fair chance. I know this sounds insane, believe
             me, I am the one that has to speak with teh
   JeremyG > investors. They have brought in some of the most knowledgable of
             computer science,
   JeremyG > inevitably they come EXTREMELY skeptical. But after they've fired
             question after question (bound by a non-disclosure
   JeremyG > agreement, unlike this by the way) they almost always leave
             recommending it to those who would invest money.
   JeremyG > Some questions are dodged for OBVIOUS reasons I hope. I don't mean to
             be rude, but there is such a thing as not
   JeremyG > disclosing something because of legal purposes. If you think I am
             going to reveal in full detail all of the inner
   JeremyG > workings of Q, DREAM ON... GA

  Dagorgil > Since you claimed that memory protection works even on a machine
             with no MMU, would you explain what happens when you run a program
             that takes a pointer as input and does something with it?  And with
             no VM, programs that do malloc(realmemsize+!)

   JeremyG > The program is processed before it ever runs. It is called a "prep"
             cycle, and could not possible conflict with other
   JeremyG > programs even if it was specifically designed to do so. In other
             words, I could write a program that would trash the
   JeremyG > hard drive, but as it is passed through the prepping cycle Q realizes
             that it goes outside of its specified domain and
   JeremyG > does one of many things: doesn't allow the program to be run at all,
             rewrites the program to run properly (if at all possible)
   JeremyG > , alert the user, etc. Good question though. GA

    W1zard > So if I plug my Amiga running Q-OS into a CRAY, then Q will
             immediately re-configure to make use of the extra CPU horsepower?

   JeremyG > If you have the proper description modules (i.e. the hardware and
             processor descriptions of the Cray), YES.
   JeremyG > Obviously you are limited by bottlenecks such as the network speed,
             etc. OF COURSE it is REQUIRED that Q be running on the
   JeremyG > Cray as well. GA

     TaoTe > "How does Q stack up against Windows NT?  What about OLE and the
             Common Object Model?  Does Q support virtual memory?  Does it
             support a GUI like Intuition?
     TaoTe > What methods exist in Q, for interprocess communication and
             multiprocess cooperation?"

   JeremyG > As far as Windows NT, no comparison... Q uses it's own form of object
             orientedness and is incompatible with others UNLESS
   JeremyG > a description module is written. Virtual memory is obsolete with Q
             technology and is no longer needed. Because Q is able
   JeremyG > to manipulate programs in real time as resources are made available
             its natural resource management system replaces
   JeremyG > any need for virtual memory. The performance increase because of this
             alone is significant. As I have previously mentioned,
   JeremyG > it is interface independant and it has SEVERAL GUIs. By default, when
             installed, it will take on the form of your
   JeremyG > previous interface. In other words, installed on an Amiga, it will
             come up looking, and responding, very similar to
   JeremyG > intuition. This will probably make a few of you flip out, I'm sorry,
             that's simply how it works.
   JeremyG > Yes, that does mean if you have extra programs running such as
             Directory Opus or ToolManager, those interface alterations

 MrGandalf > "I think for people to get the idea that this might actually exist,
             spec sheets and snapshots should be made available as soon as
             possible."  [I agree! -Sch]

   JeremyG > are ABSORBED as well... It can be changed easily, and each user may
             have his/her own interface.
   JeremyG > GA

     Cappy > I'd like more detail on this network thing with writing its own
             protocols.  Will the networking support 802.2?

   JeremyG > I have no idea what 802.2 is. Again, if it has a descriptor, it is
             supported. Often, if possible it is auto-detected.
   JeremyG > For example, lets say that you have a network of non-Q systems,
             networked though Ethernet running a TCP-like protocol and
   JeremyG > you want to attach a Q system to it, if you have the TCP decsriptor,
             you need to give it some info and then you will be
   JeremyG > running along like any other networked computer. The real advantages
             come when you hook Q machines up. Then it has the freedom

     Cappy > "You obviously know nothing about networking standards"

   JeremyG > to change the protocol to match various conditions. If the data
             integrity of a connection suddenly drops, Q will alter the
   JeremyG > protocol to a more stable one. It is true that I know little about
             networking standards, but I don't have to. I am not the
   JeremyG > one writing those descriptors. My specialty is the core of Q. I have
             written only a few of the classes and one interface.
   JeremyG > All of the rest is done by other employees of Pure Logic Enterprises.
             GA

 Bloodhawk > "What WELL KNOWN Amiga users/developers are beta testing this?" (GOOD
             question! :)

   JeremyG > None. All beta testing up until now has been privately done for
             reasons already explained. This is not a normal product.
   JeremyG > Don't expect it to operate through methods that you are familiar
             with. It will be opened up for PUBLIC beta-testing at
   JeremyG > the demonstration in December.
   JeremyG > GA

      DoZE > "How many people have been working on this?"
      DoZE > add on to that "What have you successfully run on this system?"

   JeremyG > There is 3 working full time, and others we give projects to such as
             specialty hardware etc. We have tested
   JeremyG > several products from various sources and have not had any problems
             yet. We are going to have a DOOM demonstrated running
   JeremyG > on an Amiga 3000 with a graphics card in our demonstration if ID
             Software permits us to. The most difficult programs
   JeremyG > to get to work properly are Amiga games, as they are often far more
             complex than most system-friendly software. It is just
   JeremyG > as difficult for Q to run an Amiga game on an Amiga as it is to run
             an IBM game on an Amiga. Everything is foreign to Q. GA

       Sch > Note: if you can't get Id to let you demo it, try Rise of the Triad,
             Dark Forces, etc... don't just say "Oh screw it."
       Sch > Next Question from Cryo

   JeremyG > Oh, we intend to. There are several options that would be quite
             impressive if we could demo.

       Sch > "How much Amiga kernel source was used to create his new "OS?"  [Cryo
             - wondered when you'd get here :) -Sch]

   JeremyG > None was needed. Current programmers are familiar with older style
             philosophies. With Q,
   JeremyG > all it needs is a description of what various routines are SUPPOSED
             to do, and it hums along fine. Sometimes we
   JeremyG > have serious problems, but we have invariably returned to find that
             our OS description modules weren't coded quite
   JeremyG > right (maybe we didn't understand ALL that the function was supposed
             to perform, and problems result).
   JeremyG > GA

  Fastlane > "What is your email address and usual IRC nick?"  [And - do you plan
             to frequent the 'net/IRC at all?  -Sch]

   JeremyG > I don't think that I want to give out my email address, I get too
             much as it is. I will probably be known in IRC
   JeremyG > as JeremyG, unless I embarass myself too badly and have to change
             it... :)
   JeremyG > GA

       Sch > err
       Sch > POAG

   JeremyG > No, that was a different person... sorry for the confusion. GA

   W1zard > "Will there be an entrance fee to see the demo in December?  If so,
             how much?"

   JeremyG > No entrance fee. You are right, Fastlane, I am on POLT's computer
             right now, but I assure you that I've never been on
   JeremyG > IRC before, I usually mess around with more primitive users groups
             such as usenet. This IRC stuff is cool :) GA

  Wyrehead > "What support will there be for Gfx cards?  Will Q be able to
             autodetect how to access them or will it just translate existing
             drivers...?"

   JeremyG > In some cases it can auto-detect, but more often than not it will
             "absorb" old device drivers. I know this sounds
   JeremyG > somewhat miraculous, but that's how it works... As Q classes are
             written for them, however, they will be better
   JeremyG > able to take advantage than even the previous drivers of the
             gfx/sound/etc. cards. We will either write them ourselves
   JeremyG > or get the hardware companies to make them, depending on how
             cooperative they are. GA

 Frac_unet > "Have you heard of TOAS, and are Q and TAOS in any way related
             (spiritually, in concept or do they share any code?)"

       Sch > I think thats TAOS or Taligent is what he refers to

   JeremyG > I have not heard of TAOS (what does it stand for?) GA
   JeremyG > I have heard of Taligent, but not much. If we are related it is
             because we are sick and tired of current operating
   JeremyG > systems and want to move on (maybe StarTrek's OS? ) GA

       Sch > It's a joint venture with Apple and some other company for a fully OO
             OS.

     Cappy > What is your full name and what is the name of the company you
             represent?"

   JeremyG > Jeremy Gurr, Pure Logic Enterprises, Inc. GA

      doZE > How about running something like Lightwave on this OS... does it do
             it?  Please don't be brief.

   JeremyG > Of course, it runs great. In fact, believe it or not, it was one of
             the easier ones to get working.
   JeremyG > We have only tested a faulty 3.5 though, we are waiting to get our
             hands on a 4.0 GA

  WyreHead > Does this Q mean that that things like AGA Amiga games and demos
             will work on ECS machines with a Gfx card?

   JeremyG > Yes. GA

      Litz > I would like to know how it handles encrypted self modifying
             code...

   JeremyG > It handles it quite well, thank you. Excellent question. What would
             you do, if given hundreds of years and a chunk of SMC that
   JeremyG > was compressed and encrypted and told to re-write it for another
             computer? You would go through it, step by step, writing it
   JeremyG > down as you go. And then, after you understand FULLY what is going on
             you will re-write it for your target computer.
   JeremyG > Just because it has been impossible up until now, doesn't mean that
             new methods haven't been created to do so.
   JeremyG > I can elaborate further on this if you want... just keep the
             questions coming.
   JeremyG > GA

       Sch > >>> Cryo comment "It sounds lot like Jim Drew's supposed transcription
             routines."
       Sch > Jeremy: have you talked with Jim Drew at all?

   JeremyG > Nope, and it really isn't productive to talk about it now. I'm not
             here just to waste your's and my time, believe me

       Sch > OK.

   JeremyG > we are pressed tight for time as it is. GA

      Cryo > Umm, ok, you "absorb" drivers, which means you fuzzle interrupts
             along with those, and yet you claim no Amiga kernel source is used.
             I certainly would not want to see the overhead this extra level of
             indirection causes.  It sounds like nothing more
      Cryo >  than a warm, fuzzy layer written in C++.

   JeremyG > It is NOT a level of indirection, it is part of the prepping cycle
             that only happens once. After it is complete it is coded as
   JeremyG > if it was intended to run on that machine. GA

 SmknDHerb > How/Why are you getting "too much" email if you are just now
             revealing this project?

   JeremyG > We have a lot of intersted parties (again bound by non-disclosures)
             that want to work with us. We aren't really getting
   JeremyG > "too much", I just used that as an excuse. GA

 frac_unet > "Do you need the original sourcecode of an app in order to
             "translate" it to run on Q?"

   JeremyG > No we do not. That's the whole POINT of Q is that you run an app as
             if it was designed for you computer, even if it's not. GA

     Cappy > "Where is Pure Logic Enterprises, Inc. based?"

   JeremyG > Mesa, AZ GA

  Fastlane > "Aren't there legal issues relating to Reverse Engineering of code if
             you are translating other peoples' software?  I'm sure they wouldn't
             be happy for you to be doing so."

   JeremyG > Yes, it's a big issue to. We may have to just restrict it to running
             PD code. We prefer to get with software companies and ask
   JeremyG > them to include in their license the ability to be run under a Q
             system. I can't see any reason why they wouldn't. GA

       Sch > Jeremy: restrict it in what way?  Writing?  Or encoded in the OS :)

   JeremyG > No way other than notifying the users to not run software that says
             that it can't be modified in this way.
   JeremyG > It's actually quite similar to an emulator, it just caches the
             results...
   JeremyG > GA

      NyxQ > Will I be able to run the 680x0 version of NeXTStep on my A3000
             w/Gfx Card?  And can it handle running apps for CPU architectures
             it's never seen before?

   JeremyG > YUP. GA

       Sch > uhmmm
       Sch > Can you expand upon that please.  That almost sounds impossible

   JeremyG > Ok, explain how it is impossible and I'll explain how Q handles those
             "impossibilities". GA

       Sch > JeremyG: I'll let that one go.  :|

      Litz > "How long would it take to "prep" IRIX to run flawlessly?"

   JeremyG > I've never tried it, but assuming its as complicated as I think it
             is, it could take a few days... GA

   amigama > "Does Pure Logic Ent, Inc have a phone we call reach for other info?"

   JeremyG > We would prefer that you use our web page when we get it up. I will
             have it posted as soon as it is available, and by that
   JeremyG > time I will be authorized to explain it (in the web page) in more
             depth. GA

       Nyx > What kind of OOP language features does Q support, and how does it
             compare to C++ and/or Objective-C?

   JeremyG > It is VERY different from C++, even though that is the base we
             started from. Basically EVERYTHING is an object,
   JeremyG > the keyboard, the monitor, etc. And they have operations that may be
             performed on them. Then you have a somewhat new
   JeremyG > concept that we call dependencies that make some otherwise complex
             programming quite a bit easier. For example, I could
   JeremyG > code a screen blanker, something that would alter a "screen" object
             after the "input" family of objects hasn't been altered for
   JeremyG > a period of time. The "dependency" that triggers the action is
             inactivity of the Input object for a period of time.
   JeremyG > There is a tight heirarchy of objects. For example the input object
             has the keyboard, the mouse, and the
   JeremyG > joystick objects as children. These children inherit all formal and
             informal attributes as well as all operations
   JeremyG > pertaining to the parents, allowing the children to further specify
             operations and attributes.
   JeremyG > I could go further on this if you want. GA

     TaoTe > What mechanisms does Q have to support inter-process communication
             and multi-applications cooperation?

   JeremyG > Interprocess communication has been raised to whole new levels with
             Q. Such a thing as message ports and arexx
   JeremyG > ports are no longer needed. Let me give an example that may
             illustrate this. Lets say that a term program wants to send
   JeremyG > a message to another term program, trying to find out whether it has
             taken control of a serial port or not, it
   JeremyG > simply refers to the other program by name and searches through it's
             heirarchy of resources. Sorry, sloppy example.
   JeremyG > I've got an idea, give me an example, and I'll explain how it would
             work with Q. GA

      RobB > Is "Q" going to be on a ROM or completely software based?

   JeremyG > It will at first be completely software based, although it would boot
             a bit quicker and use less space if it could be place
   JeremyG > d in ROMS.
   JeremyG > GA

      Cryo > "Show us some startup code"
       Sch > uhuh
       Sch > I don't think we have time for that.. ;)
       Sch > jeremy: how fast are you at typing example code out of your head?

   JeremyG > Not quite that fast... GA

      Litz > "What is IRIX?"  [Addressed directly to you, Jeremy]

   JeremyG > Isn't it a UNIX derivative for a Silicon Graphics machine? If you
             want to know how little I know (or care) about
   JeremyG > other OSes, I just don't have time to analyse and study all of them,
             we've got others that work for us that are supposed
   JeremyG > to design the OS description modules, and later on we will probably
             even make one for IRIX. GA

      NyxQ > How about subclasses?  Inheritance?  What kind of method binding
             does it use?  How does it
      NyxQ > figure out the details of a new CPU that it's never seen before?
             Does it just use osmosis to determine what each bit in an
             instruction uses?
      NyxQ > How does it know how long the instructions are?"

   JeremyG > First about CPUs it has never seen before. I am sorry if I seemed to
             imply that it can magically handle cpus it has never
   JeremyG > seen before, but as I have already explained, it requires a processor
             description module for each processor before it can
   JeremyG > do ANYTHING with that processor's code.
   JeremyG > About subclasses and inheritance, I'll give you a quick Q programming
             lesson. A Q class is actually an object possessing of
   JeremyG > certain attributes. If I want to make another object with similar
             attributes, I would create it with reference to the parent
   JeremyG > object. It may be composed of other objects in a wide variety of
             different ways. It has both Formal and Informal attributes.
   JeremyG > The formal attributes are those that specifically describe what an
             object is composed of. The informal attributes are
   JeremyG > those that are actually "contained" within the object, such as it's
             name, it's size, and other tagged attributes. For
   JeremyG > example, if I wanted to make a picture that only I had access to
             (without going through normal access methods) I would
   JeremyG > attach an informal attribute called "WhosAllowed" and set it equal to
             my user name. Then I would create a dependency that
   JeremyG > would only allow user's with my user name to access it. Yet this
             attribute isn't actually contained in the picture (it
   JeremyG > would mess up the format). I could go on... GA

       Ezy > "Do you really expect anyone to believe this code translation thing
       Ezy > out proof?  -- Why are you on IRC talking about it
       Ezy > d not giving lectures at a CS composium?"

   JeremyG > It has been done before, just on a smaller scale. But that was back
             when computers weren't quite so powerful. There is no
   JeremyG > better proof that I can give than the actual thing, which won't be
             long before it's available, one way or another. GA

       Sch > Jeremy: When are you meeting with Amiga Tech?

   JeremyG > We were supposed to meet with them Saturday (tomorrow for us), but
             apparently that fell through. They said that it was hard
   JeremyG > to believe (understandable) but that they would be at COMDEX and
             could maybe stop by on the way home. Then they never got
   JeremyG > back with us... We will try and get with them again, but they are by
             no means the only ones we are interested in. GA

RobR/Jacob > Will Q run MUI 3.0 and how does it handle bad programs like
             AMosaic?

   JeremyG > Q will run anything the Amiga does, and *SOMETIMES* more. At the very
             least, AMosaic won't take your system down. But it is
   JeremyG > possible that it will actually function with less problems, as Q does
             resource analysis. GA

     xterm > Just what makes you think that your nifty translation will work?  If
             it's so cool, why haven't REAL OS-innovations
     xterm > (read: AT&T, IBM, USL/Unix, MicroSoft(yes), etc.) done this yet?  And
             if you can do this, why start on the Amiga?  Why not
     xterm > a platform where you'll sell a hell of a lot more copies of the OS?

   JeremyG > This "nifty translation" has been working for quite some time. It's
             just a matter of getting some of the more difficult
   JeremyG > bugs eliminated. Why start on the Amiga? We didn't START on anything.
             The Q code is completely independant of ANY machine. We
   JeremyG > wrote the Amiga hardware and processor descriptors first because not
             only are they readily available (to us) but they
   JeremyG > provide a great test for Q's abilities: a complex piece of hardware
             incompatible with about everything, even older versions
   JeremyG > of itself. Who could ask for a more ideal proving grounds? Why hasn't
             larger companies come up with it? That question has
   JeremyG > been asked throughout the ages everytime a new invention comes, as it
             so often does, from a small establishment when
   JeremyG > much larger ones have been working on those problems for years. GA

       Sch > Addendum to xterm's Question:

       Sch > The other OS authors have access to better hardware than the Amiga or
             PPC's... the could have easily done it there.

   JeremyG > If they dared challenge the current philosophies they would have long
             ago, but as is so often the case...GA

      Cyro > "Will Q run BeBox programs?  It'd be way cool if it did."
      Cryo > :)

   JeremyG > As answered MANY TIMES before, if it is properly described, it will
             as much as your hardware is capable... No you can't run
   JeremyG > DOOM on a pocket calculator, but give it an Amiga 500, and it stands
             a chance (slow but possible). GA

      Litz > "So, if you can "prep" IRIX in a few days, why haven't we seen
             something useful yet?  Like a PPC version of AmigaOS?  Or perhaps a
             blender with the Q-OS?"

   JeremyG > Cuz yer not ALLOWED to see it yet... can't you guys realize that some
             things need some extra time to be properly protected,
   JeremyG > and that releasing stuff like that could seriously jeopardize it? Any
             patent attourneys on here? GA